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Background of the Invention 
Field of the Invention 

The present invention is related to resource and revenue management, 
and more particularly to a system and method of determining a value of a cus- 
tomer based on past activities of the customer. 

Description of the Background Art 

In many industries, providers of products and/ or services fail to take into 
account indirect value that derives from the sale of the product or service, when 
determining a price for a particular customer or customer segment. Examples of 
such indirect value include advertising revenue, increased sales of related or un- 
related goods or services, increased website traffic, increased revenue from re- 
lated or unrelated business enterprises, and the like. Though such sources of in- 
direct value can be quantified based on customer segment, demographic and/ or 
psychographic categorization, observed or predicted behavior, and the like, 
existing revenue management systems fail to take into account such sources of 
indirect value in a systematic manner when determining whether or not to offer 
a resource to a particular customer or customer segment, or when determining a 
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price point for offering such a resource to a particular customer or customer 
segment. 

One example where such indirect value is a substantial component of 
overall profitability is the casino/ hotel industry. Casinos and hotels are often 
affiliated with one another, and in many cases are operated by the same com- 
pany. Most casino/ hotel operators recognize that potential income from the ca- 
sino often far exceeds income from renting rooms at the hotel; yet the hotel com- 
ponent of the business endeavor is a necessary element to attract customers. 
Thus, many such operators are content to make little or no profit (or even lose 
money) on their room prices in order to attract customers; the operators rely on 
increased casino profits from these customers to offset the discounted room 
prices. As a common enterprise, casino/ hotel operators are primarily interested 
in maximizing total profits, and are willing to take a loss on the hotel operations 
in order to achieve a greater total profit. 

In general, customers may be divided into segments having distinct char- 
acteristics and potential revenue or other value. For example, overnight visitors 
generate higher gaming revenues (i.e., provide greater gaming value) than do 
day trip visitors. A visitor on an overnight trip tends to do the largest share of 
his or her gaming at the casino associated with his or her hotel. Accordingly, ca- 
sino/hotel operators whose hotel customers include those overnight visitors hav- 
ing the highest gaming value generally enjoy the highest casino revenues. 
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In many areas where gaming is prevalent, hotel rooms are scarce, and cus- 
tomers are often turned away. Casino/ hotel operators try to determine how 
many rooms to rent at which price points, in an attempt to maximize revenue. 
Conventionally, room prices vary based on several factors, including class of 
room, special events, and availability. Operators forecast the number of rooms in 
demand at future dates, and set room prices based on these factors. Thus, for pe- 
riods of high demand, higher room prices may be charged. 

However, conventional techniques for setting room prices fail to take into 
account the potential gaming value of particular customer segments as compared 
with other customer segments. For example, higher-rated gaming players (i.e., 
those that belong to a customer segment associated with a higher level of casino 
profits) are more valuable to a casino/ hotel operator than are lower-rated gam- 
ing players or non-players. Industry analysis has shown that 26% of casino cus- 
tomers provide 82% of gaming revenues. Thus, where accommodations are 
scarce, it would be advantageous for hotel/ casino operators to favor higher- 
value customers over lower-value customers. Conventional room pricing meth- 
ods fail to take into account the relative gaming value of customers. 

Furthermore, many higher-rated gaming players book room reservations 
relatively late, within only a few days of their intended stay. If a hotel is already 
full by the time the higher-rated player wishes to book a room, the higher-rated 
player will be turned away. The result is that the room is occupied by a lower- 
s- 
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valued customer (who booked earlier) instead of the higher-valued customer. A 
net loss in total revenues results, due to the failure to take into account the gam- 
ing value of each potential hotel customer when pricing or offering the room. 
Indeed, in some cases, it may be desirable not to rent the room to a lower-valued 
customer at all, and instead hold open the room for a possible later-booking 
higher valued customer. 

In addition, current systems, both in the casino/hotel industry and in 
other industries fail to take into account total potential customer value, including 
indirect value, in determining whether or not to target a marketing campaign at a 
customer or customer segment, based on indirect value for the customer or cus- 
tomer segment, or on total value including direct and indirect value. As a result, 
services and/ or goods are offered to potential customers without regard to a de- 
termined or estimated total value, including indirect value. As a result, such 
businesses suffer from misallocation of scarce resources, as well as a lack of op- 
timization and profit maximization. 

The profitability model varies at various casinos. For example, a casino in 
Lake Tahoe casino is usually full. Such a casino is more profitable than a casino 
with fewer customers and, therefore, needs to give fewer incentives for custom- 
ers to attend. When determining a room rate, different casinos would categorize 
the same potential customer differently, depending on how much the casino 
wants to fill its rooms. For example, a casino that is mostly full would provide 
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very few comps and would only comp potential customers who are highly prof- 
itable. In contrast, casinos that are less full would comp the highly profitable 
customers and, in addition, would comp additional, less profitable customers be- 
cause, even though those customers are not as profitable, it is still desirable to fill 
more rooms. 

In the past, resource management systems have not accounted for varia- 
tions in properties when categorizing customers and/ or setting room prices. 

Certain gaming types are more lucrative than other types. For example, 
table games such as keno and blackjack are more profitable for a casino than slot 
machines. In the past, casinos have valued customers who spent $200 at the slot 
machines the same way that they have valued customers who spent $200 at table 
games. This valuation is not optimum, since the table game players make more 
money for the casinos and are to be encouraged to come to the casinos and play 
more than slot machine players. 

In addition, certain casinos do not have all types of games. For example, 
many casinos on Indian reservations do not have table games. Thus, a customer 
who only plays table games would not be as valuable to this type of casino. It 
would be desirable to take differences in casinos into account when categorizing 
customers based on their past actions. 
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Summary of the Invention 

An embodiment of the present invention manages and optimizes total 
customer value on a property-specific basis and by further considering customer 
activities across multiple affiliated properties in a chain of properties. For ex- 
ample, the customer valuation system may determine a customer's value by 
looking at the customer's activities for all affiliated casinos in a casino chain. 
Similarly, the customer valuation system may determine a customer's value by 
looking at the customer's activities for all casinos at hotels in a chain of hotels 
and casinos. Similarly, the customer valuation system may determine a cus- 
tomer's value by looking at the customer's activities in some, but not all of the 
casinos in a chain. 

In an embodiment, a customer valuation is first determined at reservation 
time. The customer value is based on an expected average profit for a customer 
based on the customer's activities in multiple hotels/ casinos in a chain of ho- 
tels/ casinos. Once an expected average profit is determined for the customer, 
based on his past activities, a control segment is determined for the customer, 
depending on which property he is interested in. A reservation management 
system uses the control segment to determine possible room rates that might be 
offered to the customer based on his control segment. The same customer activi- 
ties may result in the customer being categorized into differing control segments 
for different properties. 

-7- 

Case 6497 

19538/06497/DOCS/1224713.3 



The present invention can be applied to allocation and pricing for any re- 
source having multiple quantifiable sources of value, such as direct and indirect 
value that are capable of being determined, estimated, or predicted. For exam- 
ple, tickets to entertainment events, hotel services, and other resources may be 
dynamically priced, taking into account indirect value such as shopping, dining, 
and the like, for the customer or customer segment. The determined indirect 
value may be based on demographic and/ or psychographic characteristics, ob- 
served and/ or predicted behavior, or other factors. 

The present invention further provides functionality for targeting market- 
ing efforts. By taking into account a determined or estimated indirect value for a 
customer or customer segment, the invention determines whether or not to target 
a marketing campaign at a customer or customer segment, and determines an 
offer price for the customer or customer segment. 

In one embodiment, the indirect values for multiple customers can be 
combined as inputs into the resource manager. For example, when a customer is 
booking a room at a hotel, it is typical that there are several others in the cus- 
tomer's party. Each of these members of the customer' s party is a source of indi- 
rect revenue to the hotel operator, for example, from their gaming or other activ- 
ity. Accordingly, to better price the hotel room offered to the customer, in one 
embodiment, the indirect value of each member of the customer's party is ob- 
tained. This can be done by looking up in database, or computing, the indirect 
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value of each member of the customer's party. In an embodiment where the in- 
direct value is measured by the gaming value of the customer, such as the cus- 
tomer's theoretical win amount, the indirect values of all members of the party 
can be used to affect (weighted or unweighted) a single indirect value. In one 
embodiment, the indirect values are combined. In another embodiment, the in- 
direct values of one customer is increased in accordance with the number of ad- 
ditional customers in the room. 

In various embodiments, selected historical transactional or behavioral in- 
formation about the customer is used to generate an indirect value for using in 
pricing the requested resource. In one embodiment, the customer's indirect 
value is derived from prior transactions between the customer and the provider 
of the resource. In the embodiment where customer is being offered a room at a 
hotel and casino, the indirect value can be derived from the customer's gaming at 
the casino (or affiliated casino properties). Here, the indirect value is based at 
least on the customer's theoretical win. When a customer stays at a hotel, his in- 
direct value is higher, since customers tend to gamble more at the hotel, and also 
shop and eat more at the hotel. When the customer merely games at the hotel 
without lodging there, their indirect value is typically lower. Accordingly, in one 
embodiment, when pricing a hotel room for a customer, the indirect value of the 
customer is determined only from prior stays at a hotel property, and excludes 
indirect value from those trips where the customer did not stay at the hotel. 
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Brief Description of the Drawings 

Fig. 1 is a conceptual block diagram of the functional components of the 
invention according to one embodiment. 

Fig. 2A is a flow chart showing overall operation of a revenue manage- 
ment system employing the present invention. 

Fig. 2B is a flow chart showing a process of generating a price for a re- 
source according to one embodiment of the present invention. 

Fig. 3 is a block diagram showing system components of one embodiment 
of the invention. 

Fig. 4 is a screen shot of a recommendations review screen for a user inter- 
face according to the present invention. 

Fig. 5 is a screen shot of an adjust bid price screen for a user interface ac- 
cording to the present invention. 

Fig. 6 is a block diagram of a network configuration for implementing the 
present invention. 

Fig. 7(a) is a flow chart showing a relationship between an embodiment of 
the present customer evaluation method and system and a resource management 
system, such as that shown in Figs. 1-6. 

Fig. 7(b) is a flow chart of three contexts in which a customer valuation 
method and system might be used. 
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Fig. 8 shows a data structure used by the customer valuation method and 
system containing property-specific flags and values. 

Fig, 9 shows a data structure used by the customer valuation method and 
system and containing values associated with a customer source code. 
5 Fig. 10 shows a data structure used by the customer valuation method and 

system and containing values associated with a daily profit determination. 

Fig. 11 shows a data structure used by the customer valuation method and 
asystem and containing values associated with a nightly profit determination. 

Fig. 12 shows a data structure used by the customer valuation method and 
W system and containing values associated with control segments and customer 
segments. 

Fig, 13(a) is a flow chart showing an overview of the customer valuation 
method used with a reservations operation. 

Fig. 13(b) is a flow chart showing an overview of the customer valuation 
25 method used with a booking operation. 

Figs. 14(a)-14(c) are flow charts showing details of the customer valuation 
method used with a reservations operation. 

Fig. 15 is a flow chart showing details of the customer valuation method 
used with a booking operation. 
20 Fig. 16 is an example screen shot of a reservation screen showing a best 

rate available based on a determined customer value. 
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The drawings provided herein are merely illustrative of one embodiment 
of the invention. One skilled in the art will recognize that many other architec- 
tures, process implementations, and screen designs are possible without depart- 
ing from the spirit or essential characteristics of the invention. 

Detailed Description of the Preferred Embodiments 
Definitions 

For the purposes of the following description of the preferred embodi- 
ments, the following terms are defined. These definitions are not intended to 
limit or restrict the scope of the present invention, whose scope is defined solely 
by the claims. 

• Resource: A quantifiable, saleable commodity or service that is typically 
provided to a customer in exchange for payment. In the context of this in- 
vention, resources are assumed to be finite in quantity and/or availability. 
Examples: hotel rooms, air travel, concert tickets, soap, tomatoes. 

• Value: Quantifiable benefit to the provider of the resource, deriving di- 
rectly or indirectly from a customer's consumption of the resource. Ex- 
amples: revenue, profits, advertising exposure, public relations. 

• Customer segment: A subset of customers or potential customers, based 
on some common characteristic. May include zero or more customers or 
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potential customers. Any number of customer segments may be defined 
for the set of all customers or potential customers. 

Direct value (primary value): Revenue, profit, or other value collected di- 
rectly from customers and deriving directly from sale of the resource. Ex- 
amples: room rates (for hotel rooms), airfare (for air travel), selling price 
(for goods). May be measured, for example, in terms of gross revenue or 
profits; may or may not take into account costs of providing the resource. 
Indirect value (secondary value): Any additional revenue, profit, or other 
value, aside from the direct value, that results from the customer's pur- 
chase, consumption, or use of a resource. Examples: gaming revenue re- 
sulting from a hotel room stay, advertising exposure resulting from pur- 
chases of associated goods, expected gift shop revenue resulting from a 
theme park admission. May be measured, for example, in terms of gross 
revenue or profits; may or may not take into account costs of providing 
the resource. May represent value associated with an increased probabil- 
ity of additional revenue. May be determined on an individual customer- 
by-customer level, or on a segment-by-segment level. 
Actual indirect value: Measured indirect value (such as revenue) for a 
particular customer or customer segment, determined for example from 
past resource use, purchases, consumption or transactions. 
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• Expected (or predicted) indirect value: Indirect value that can be rea- 
sonably expected from a particular customer or customer segment for a 
particular purchase, consumption, use, or transaction. Expected indirect 
value may be based, for example, on one or more of actual indirect value 
(such as revenue from past purchases) and/ or predictions based on any 
available information about the customer or customer segment, such as 
demographic characteristics, psychographic characteristics, and/ or spe- 
cific historical transactions. In one embodiment, the expected indirect 
value is determined using a predictive model. 

• Total actual value: The sum of direct value and actual indirect value. 

• Total expected value: The sum of direct value and expected indirect 
value. 

Functional Components 

The following description illustrates the invention in the context of a sys- 
tem for of allocating and pricing hotel rooms by taking into account gaming 
value of potential hotel customers. However, the present invention can be ap- 
plied to allocation and pricing for any resource having a source of indirect value, 
and is not intended to be limited to hotel room management and pricing. Ac- 
cordingly, the context of the following description is not intended to limit in any 
way the scope of the invention, which is defined solely by the claims. 
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In one embodiment, the present invention takes into account multiple 
sources of value, including direct and indirect value, in order to determine how 
to allocate and price hotel rooms for a casino/ hotel operation. The indirect value 
may be determined based on actual historical data tracking, predictive modeling, 
5 estimates, demographics, psychographics, and/ or any other relevant factors. 
Customer segmentation may be employed in order to determine and provide 
such indirect value measurements. 

Referring now to Fig, 1, there is shown a conceptual block diagram of the 
^ functional components of the invention according to one embodiment. In one 

• H 

u[| 10 embodiment, the various functional elements of Fig. 1 are implemented as soft- 
CP 

yj ware components running on a conventional personal computer, as is known in 

% the art. 

H' Optimizer 103 generates a recommendation 105 in response to a resource 



Ji! request for a particular customer or customer segment. Recommendation 105 
15 includes, for example, an indication as to whether the resource should be made 
available to the customer or customer segment, and/ or a recommended price for 
the resource. 

For illustrative purposes, Fig. 1 shows examples of the types of input that 
may be provided to optimizer 103 in generating recommendation 105. One 
20 skilled in the art will recognize that the illustrated input types are merely exem- 
plary, and that other factors may be taken into account in generating recommen- 
ds - 
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dation 105, In the illustrated embodiment, historical demand 100 and current 
bookings 101 are provided to a forecaster / demand predictor 102, which fore- 
casts demand for particular customer segments. Indirect value 106 (such as cus- 
tomer gaming value), along with forecasted demand developed by predictor 102, 
are provided to optimizer module 103. As described above, indirect value may 
represent actual measured value, estimated value, or any combination thereof. 
Indirect value 106 may be provided according to individual customers, or ac- 
cording to customer segments, as desired. A further input that may be provided 
to optimizer 103 is an indicator of competitive market pressures or other envi- 
ronmental factors, such as prices for similar resources available from competitors 
(e.g. room prices at competing hotels). Additional input and adjustments may 
also be provided such as for example an indication of expected or actual demand 
cycles, so as to increase prices when demand is strong. 

Taking into account input from predictor 102, indirect value 106, and data 
describing the competitive environment 104), optimizer 103 generates a recom- 
mendation as to the appropriate resource allocation and prices, in order to 
maximize total value. Recommendation 105 may be in the form of a price to of- 
fer to a customer, or a recommendation that the resource not be made available 
to the customer. 

Thus, in the context of a casino/hotel operation, recommendation 105 en- 
sures availability for high-gaming-value customers when appropriate, and 
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makes appropriate trade-offs to ensure availability for mid- gaming-value cus- 
tomers when appropriate. 

Resource Pricing 

Referring now to Fig. 2B, there is shown a flow chart depicting a process 
of generating a price for a resource according to one embodiment of the present 
invention. In the context of a casino/ hotel operation, for example, the steps of 
Fig. 2B may be performed when a customer, potential customer, or sales agent 
requests a hotel room at a particular hotel property. 

The request for the resource (such as the hotel room) is received 251 by the 
system. In one embodiment, a customer segment for the customer is determined 
252. The Segment may be defined, for example in terms of various characteristics 
of the customer. As described in more detail below, these characteristics may in- 
clude behavioral, demographic, psychographic, or other descriptive factors. 
Customer segmentation allows the resource pricing implemented by the present 
invention to be performed on a segment-by-segment basis, so that once a particu- 
lar customer's segment is determined, an offer price can be generated based on 
the indirect value associated with the customer segment. However, one skilled 
in the art will recognize that customer segmentation is not required, and that re- 
source allocation and pricing recommendations may be made for individual cus- 
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tomers without employing customer segments and without departing from the 
essential characteristics of the present invention. 

Based on the customer segment (or, alternatively, based on information 
describing the individual customer), an indirect value for the customer is deter- 
mined 253. In the context of the casino/ hotel operation, such indirect value may 
represent, for example, gaming revenue that is expected to result from the cus- 
tomer's stay at the hotel. Other types of indirect value may also be determined, 
as described above. The indirect value may be an expected or actual value, and 
may be determined based on statistical, predictive, empirical, or other methods. 

An initial bid price is obtained 254 for the resource being requested by the 
customer. This price is determined by conventional means, and may be based on 
any combination of factors, such as the type of resource, availability, demand, 
competitive market forces, promotions, and the like. Thus, the initial bid price 
represents the unadjusted price that would normally be charged for the resource, 
without taking into account indirect value of a particular customer or customer 
segment. In one embodiment, the initial bid price is adjusted by various mecha- 
nisms, as described in more detail below. 

The system then determines 259 whether the resource should be offered to 
the customer making the request. In one embodiment, this determination is 
made based on the indirect value of the customer; thus, a customer would only 
be offered the resource if his or her indirect value (expected or actual) exceeded a 
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threshold value. The threshold value may be fixed, or may depend on availabil- 
ity, day of week, season, or other factors. Thus, in the casino/ hotel example, a 
room might be offered to a customer only if the expected or actual gaming reve- 
nue from the customer exceeded a threshold value. 

In an alternative embodiment, the determination in step 259 is made 
based on the total value of the customer, taking into account both direct and in- 
direct value. A total value is determined by combining the initial bid price with 
the (expected or actual) indirect value, and adjusting the bid price if appropriate. 
If and only if the total value exceeds a threshold, the resource is offered to the 
customer. Figs, 7-16 show an example of a customer valuation method for de- 
termining one type of indirect value. 

If in step 259 a determination is made that the resource should not be of- 
fered to the customer, the resource is denied 260 to the customer. 

If in step 259 a determination is made that the resource should be offered 
to the customer, the system, in one embodiment, adjusts 255 the initial bid price 
to take into account the indirect value of the customer. Such an adjustment may 
be made, for example, by subtracting the indirect value (adjusted by a multiplier 
value, if desired) from the initial bid price. A minimum adjusted bid price may 
be set. In an alternative embodiment, step 255 is not performed, and the system 
does not adjust the initial bid price. 
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In one embodiment, the system performs the optional step of adjusting 

256 the bid price further, to account for market factors such as competitive pres- 
sures. For example, if competing hotels are offering rooms at lower prices, the 
bid price for a room may be adjusted downward in order to remain competitive. 

Once all desired adjustments have been made, the resource is offered 257 
to the customer at the quoted price. 

By performing the above-described steps, the present invention is able to 
determine, based on indirect value of a customer, whether or not to offer a re- 
source to a customer and at what price to do so, in order to optimize resource al- 
location and total revenue. 

In an alternative embodiment, the above-described steps are performed in 
the context of implementing a marketing campaign, so that prospective custom- 
ers are offered the resource if their indirect or total value exceeds a threshold 
value. In such an implementation, the above-described steps are initiated in the 
course of conducting a marketing campaign, rather than in response to a cus- 
tomer's request for a resource. Thus, for example, the above-described analysis 
might be performed for a set of potential customers, and direct-mail (or other) 
offers might be made to a subset of the customers, based on their indirect or total 
value. The offer prices may be tailored to each customer or customer segment, 
based upon indirect or total value and employing the same value-maximizing 
techniques described above. 
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Forecasting and Optimization Model 
Revenue management Product 

In one embodiment, the present invention is implemented in conjunction 

with or as a component of a Revenue Management Product as is known in the 

art. Accordingly, the following description of preferred embodiments of the pre- 
sent invention discusses the invention in the context of such a product for reve- 
nue management in a casino/ hotel operational context. The particular imple- 
mentation discussed herein is merely illustrative, and the particular characteris- 
tics and operating schemes of the implementation are not intended to limit the 
scope of the claimed invention. 

Conventional revenue management processes for casino/ hotel operations 
attempt to forecast demand and optimize room prices at the revenue manage- 
ment product level. A revenue management product represents a hotel stay and 
thus has four primary attributes; arrival date, length of stay, room category, and 
customer segment. A bid price offered to a consumer may depend on any or all 
of the attributes of the hotel stay. 

• Arrival date: the date for which the forecast is made, typically the day the 
customer arrives at the hotel; also referred to as day zero. 

• Length of stay: the number of room nights the customer spends in the ho- 
tel. 
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Room category: one of any number of predefined room categories, or types. 
In one embodiment, five room categories are provided, denoted A (high- 
est value) through E (lowest value), plus a sixth category, denoted F, to 
represent unmanaged rooms for which the system does not forecast de- 
mand nor provide inventory control. 

In one embodiment, all rooms within a particular room category are con- 
sidered equivalent. Rooms in different room categories are considered to 
be in distinct and separate inventories. As described below, demand is 
forecasted and optimized separately for each room category. 
If desired, subgroups may be created within room categories, and incre- 
mental or intermediate prices may be established for the sub-groups. In 
this manner, the spread between quoted room prices for the sub-groups 
can be controlled, and upgrades from one room category to another can be 
selected based on sub-groups. Rooms within a sub-group are treated as a 
single inventory for purposes of the present invention. 
Customer segment: In one embodiment, customer segments are defined in 
order to provide greater forecasting accuracy and to ensure that bid prices 
(i.e. room prices offered to customers) generated from the optimization 
process will maximize potential value. Customer segments may be de- 
fined based on any combination of factors, including for example demo- 
graphic, psychographic, and behavioral observations and predictions. In 
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one embodiment, 64 customer segments are defined. 
Segments may be further defined according to whether the customer is in- 
cented or un-incented. Incented means the customer has been sent a spe- 
cial offer or invitation to a special event. 

In one embodiment, an expected indirect value, such as gaming value, is 
associated with each customer segment. The gaming value can be deter- 
mined, for example, based on statistical analysis of gaming behavior in- 
formation collected from customers. The determined value may be con- 
tinuous or in ranges. In one embodiment, there are six levels of nightly 
gaming value, including: $0-49; $50-99; $100-149; $150-199; $200-299; and 
$300+. In addition, the system may provide two levels for unknown 
status (based on estimates): $0-49; and $50-99. These ranges may be 
changed as desired, and may be specific to different properties. Those of 
skill in the art will see that more or fewer ranges may be used, and the 
range bounds may be changed as desired. A room price may be associ- 
ated with each level of gaming value, if desired. In one embodiment, 
there are 12 room rate types, including Comp, Casino, General Reserva- 
tions 1 through General Reservations 8. 

A room price can be established for the customer segment based on the 
indirect value. A total value for a customer within the customer segment can be 
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determined by adding the average nightly gaming value to the established room 
price. 

For example, if it is determined that a customer segment having a nightly 
gaming value of $100-149, a room price of General, and a channel of incented has 
an average nightly gaming value of $132, the discounted room price may be set 
at $165, giving the segment a total value of $297. The method by which the room 
price is established will be described in more detail below. 

Bid Prices 

A bid price is a price at which the resource is offered to a customer. In one 
embodiment, the present invention tracks up to five types of bid prices: an initial 
bid price, a optimal bid price, a recommended bid price, a competitive intelli- 
gence (Cl)-adjusted bid price, and a user-adjusted bid price. 

Initial Bid Price. The initial bid price does not take into account the gam- 
ing value for the customer segment. The initial bid price is derived by well- 
known mechanisms for setting prices for resources such as hotel rooms, and may 
be based on demand, availability, promotional and market considerations, and 
the like. 

Optimal Bid Price. The optimal bid price is a refinement of the initial bid 
price, and may be segmented according to subcategories such as inventory date 
and room category. The optimal bid price is the marginal value of the last room 
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available for a particular inventory date and room category, as determined by 
techniques that are known in the art. In one embodiment, for each inventory 
date, a "cutoff " value is established to determine whether to accept or reject de- 
mand corresponding to different revenue management products. 

Recommended Bid Price. The recommended bid price is the price at 
which the system recommends the resource be offered to the customer, exclud- 
ing factors associated with the competitive environment. The recommended bid 
price is derived from either the initial bid price or the optimal bid price by taking 
into account indirect value, such as actual or expected gaming value, for the cus- 
tomer or customer segment. In one embodiment, the indirect value is discounted 
by a predefined percentage associated with the particular customer segment. 
This predefined percentage can be set as desired for each customer segment, 
based on external factors or user preferences. The discounted indirect value is 
subtracted from the optimal bid price to determine the recommended bid price. 
For bid prices that fall below a certain minimum, a predefined "comp" or "ca- 
sino" price can be substituted. 

For example, the optimal bid price for a particular inventory date and 
room category might be $225, while the actual or expected gaming value for a 
particular customer segment for that date might be $200. If a 50% discount is 
applied to the gaming value, a recommended bid price of $125 would be gener- 
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ated. This is calculated by taking the gaming value ($200) after the 50% discount 
($100), and subtracting it from the optimal bid price ($225). 

CI- Adjusted Bid Price. The Cl-adjusted bid price is derived from the rec- 
ommended bid price, and further takes into account the competitive environ- 
ment. Competitive prices are provided to adjust the recommended bid price, 
when appropriate, to be in line with the competition and with market pressures. 
The Cl-adjusted bid price may be activated or deactivated by the user, as desired, 
and may be the basis for the price at which the resource is offered. 

In one embodiment, the Cl-adjusted bid price is determined as follows. A 
set of competitive properties is determined, and a market composite rate is estab- 
lished based on the rates charged by the competitive properties. The difference 
between the recommended bid price and the market composite rate is then de- 
termined. The result is adjusted based upon a weighting factor, which may de- 
pend on the booking window for the requested reservation. If the Cl-adjusted 
bid price is below a predefined minimum room price for a given customer seg- 
ment, the bid price may be adjusted upward as necessary. 

For example, if the weighting factor for a particular booking window is 
75%, the recommended bid price will be adjusted by 75% of the difference be- 
tween the recommended bid price and the market composite rate. If the recom- 
mended bid price is $175 and the market composite rate is $135, the Cl-adjusted 
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bid price would be adjusted downwards by ($175 - $135) * .75, or $30, resulting in 
a value of $145. 

User-Adjusted Bid Price. Once a user has been presented with a recom- 
mended bid price or a Cl-adjusted bid price, he or she may adjust the bid price if 
desired, or may override the recommendation altogether. In one embodiment, 
the present invention tracks user adjustments and takes such adjustments into 
account when generating bid prices, or when developing statistics for future 
analysis. 

In one embodiment, a set of predefined prices is established, and the bid 
price generated by the invention serves as an indicator as to which of the prede- 
fined prices should be made available to a particular customer. For example, if a 
recommended bid price (or Cl-adjusted bid price) of $89.52 is generated by the 
system, and the predefined room prices for the hotel include $75.00, $110.00, and 
$150.00, then the room may be offered to the customer at $110.00, representing 
the lowest predefined room price that exceeds the recommended bid price. 

In one embodiment, if the recommended bid price exceeds all predefined 
prices, the system recommends that the resource be denied to that customer. 
Only a customer who has a high enough indirect value to reduce the bid price 
below at least one of the predefined prices is offered the resource. In an alterna- 
tive embodiment, the system only recommends that a customer be denied a re- 
l- 
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source when there is enough demand at higher levels of indirect value to con- 
sume the resource. 

Gaming Value Tracking 

As discussed above, one example of indirect value that may be deter- 
mined and employed in the context of the present invention is gaming value. 
Thus, in the context of a casino/hotel operation, customers who generate higher 
gaming revenue might be offered more favorable room rates. 

In one embodiment, the gaming value may be provided as an actual value 
or an expected value. The value is determined based on actual or predicted gam- 
ing behavior by, for example, taking the average daily theoretical win and ap- 
plying property-specific profitability margins depending on game type and 
player value ranges. 

Expected gaming value (or predicted gaming value) is determined by sta- 
tistical analysis of the customer's historical gaming behavior, taking into account 
factors such as the date and time of arrival, length of stay, previous behavioral 
trends, and the like. Information about the customer's historical gaming behav- 
ior is collected using player tracking technology, such as identification cards 
which are read by slot machines and other gaming machines and which auto- 
matically track and accumulate a player's betting patterns. For table-based 
games, manual tracking of player betting may be utilized, so long as such manu- 
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ally gathered information is accumulated and maintained in the appropriate da- 
tabases for analysis. Suitable customer tracking technology is described in re- 
lated U.S. Patent Number 5,761,647, for "National Customer Recognition System 
and Method." Accordingly, the expected gaming value represents the expected 
value of the customer's gaming activity when they visit at the date specified in 
the reservation. 

Actual gaming value represents the actual observed gaming activity for 
the dates defined by the reservation, and is thus measured after the fact. 

In one embodiment, actual gaming value is provided to the system as an 
input to the system of the present invention after the customer has checked out 
of the hotel, and thus when it is too late to determine a bid price for that hotel 
stay. However, by taking into account actual gaming value, the invention is able 
to refine its estimates of estimated gaming value for the customer on future visits 
and thus more efficiently optimize revenues. In addition, actual gaming value 
may be used to refine estimates for the customer segment to which the customer 
belongs. In one embodiment, actual gaming value is used as input for the opti- 
mization process of the present invention, and is also discounted and used in a 
post-optimization process to determine optimal bid prices for customer seg- 
ments. Figs. 7-16 show an example of a customer valuation method for deter- 
mining one type of indirect value, specifically a customer gaming value, which is 
also called a customer value. 
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Overall Operation 

Referring now to Fig. 2A, there is shown a flowchart of the overall opera- 
tion of a revenue management system employing the present invention in the 
context of a casino/hotel operation. Fig. 2A illustrates an example of how the 
techniques of the present invention can be employed in conjunction with de- 
mand forecasting and other known techniques, to provide bid price recommen- 
dations that optimize resource allocation and revenue management. 

Daily demand data is extracted 201 based on bookings, cancellations, and 
denials. In one embodiment, each property runs a daily process to update values 
for all forecast statistics based on the most current day's activity. Updating is 
based on a smoothing technique, such as for example Kalman filters or any other 
similar technique known in the art. Kalman filters are similar to exponential 
smoothers, but the smoothing constant, or weight of new data, changes with time 
as the system weights average demand from the previous eight weeks more 
heavily than the most recent observation. Thus, the forecast tends to be more 
stable and does not react violently to new data points. 

Forecasted demand data is aggregated 202 into customer segments. Based 
on the aggregated data, and taking into account special events and segment 
events, demand forecasts are generated 203 for each customer segment. Gener- 
ated forecasts predict demand in terms of unconstrained arrivals, i.e. the total 
number of arrivals that would stay at the hotel if there were sufficient room for 
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all. Deseasonalized arrivals demand is multiplied by a seasonal adjustment fac- 
tor and, if necessary, by a revenue management event factor to take into account 
special circumstances and events. The resulting forecast predicts demand in 

terms of total arrivals for any given day in a year. 

For each customer segment, as well as current hotel capacity and data de- 
scribing room rates at competing local hotels, optimization 204 is performed, us- 
ing the techniques described above in connection with Fig. 2B to generate bid 
prices that maximize total revenue and optimally allocate resources. For each 
customer segment, a recommended bid price is developed that takes into account 
the expected gaming value of customers in that segment. If desired, competitive 
pressures are also taken into account, as described above. 

Optimization step 204 takes into account the remaining demand forecast 
and remaining available capacity, using techniques that are known in the art, in 
order to generate optimal bid prices by inventory date and room category. These 
bid prices are used by reservation agents to recommend room prices. In addition 
to generating recommended bid prices, the optimization step 204 generates 
overbooking recommendations based on forecasts of no-shows and cancellations. 
Overbooking recommendations are generated by inventory date and room cate- 
gory. Overbooking adjustments are added to the optimizable capacity, so as to 
define the availability of rooms for generating bid prices, according to techniques 
that are known in the art. 
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Once optimized bid prices are generated, the prices are filtered 205 to set 
appropriate prices. For example, prices may be rounded up or otherwise ad- 
justed to match industry norms, according to techniques that are known in the 
art. 

In one embodiment, filtering 205 is performed based on control segments 
determined by reference to average daily gaming values. Pricing and availability 
determinations may be made at the control segment level. For example, eight 
control segments, made up of 64 customer segments, might be established, ac- 
cording to the following table: 



Control segment 


Segment Description 


1 


Nightly Gaming Value >= $300 


2 


$200 <= Nightly Gaming Value < $300 


3 


$150 <= Nightly Gaming Value < $200 


4 


$100 <= Nightly Gaming Value < $150 


5 


$50 <= Nightly Gaming Value < $100 


6 


Nightly Gaming Value < $50 


7 


Unknown customer with expected Nightly Gaming Value >= 
$50 


8 


Unknown customer with expected Nightly Gaming Value < 
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$50 



Recommendations are generated 206 and output 207 for various rooms 
and customer segment combinations. These output recommendations take into 
account all of the above-mentioned factors, including room category, control 
segment, gaming value, and competitive information. In one embodiment, rec- 
ommendations are provided in response to individual customer requests for 
rooms; in another embodiment, recommendations are provided in connection 
with a marketing campaign, so as to provide bid prices at which rooms are of- 
fered in the campaign. 

Recommended bid prices thus take into account the gaming value of the 
customer, as well as other factors such as demand and availability. In one em- 
bodiment, a user (such as a booking agent) may override system recommenda- 
tions when quoting room prices. As discussed above, overrides or modified 
forecasts are provided as supplemental inputs to the system, and may be taken 
into account when re-optimizing to generate new recommendations for future 
room quotes. 

In one embodiment, when the user overrides the system's recommenda- 
tion, he or she may initiate re-optimization (or such operation may occur auto- 
matically), which may in turn result in updates to bid price recommendations. In 
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one embodiment, overrides are not persistent unless the user re-optimizes and 
uploads new recommendations, 

In one embodiment, user overrides are limited, so that a user may over- 
ride a bid price recommendation only by replacing the recommended bid price 
with a "comp" or casino price that may be predefined for each particular prop- 
erty. Defaults may also be provided. 

In one embodiment, overrides, whether default or manually applied by 
the user, are persistent. The identified override price remains as the recom- 
mended bid price for that property and customer segment, until otherwise 
changed. 

System Components 

In one embodiment, the present invention is implemented as a combina- 
tion of computer-implemented systems and business processes. The computer 
system for implementation of the present invention may be, for example, a Unix- 
based computer such as available from Hewlett-Packard Corporation of Palo 
Alto, California. The system of the present invention includes several interre- 
lated functional components. Each of these will be described in turn, in connec- 
tion with a system for generating bid prices for a casino/ hotel operation accord- 
ing to the present invention. 
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Referring now to Fig. 3, there is shown a block diagram of functional 
components of system 300, according to one embodiment of the invention. De- 
tails of the operation of the various functional components are also provided be- 
low, in connection with the description of the user interface according to one 
embodiment of the invention. 

System Initialization 301: Prepares file systems, creates the system data- 
base, and establishes the environment for system operation. Server platform is 
initialized and system code and databases for tracking hotel properties, book- 
ings, gaming, customers, and the like are implemented, according to techniques 
that are known in the art. 

Property Initialization 302: Prepares an individual property (hotel) for 
integration into the functionality of the system. Creates and configures a prop- 
erty database on the server platform that is ready to include in daily processing 
activity. In one embodiment, an initialization script is invoked to create the da- 
tabase, load historical data, and execute initializations, according to techniques 
that are known in the art. 

Forecaster Initialization 303: Includes long-term initialization, which 
produces seasonality and other statistics for forecaster 102 and optimizer 103. 
These values are derived from analysis of historical demand patterns for each 
property. Default statistical values for forecasting are developed. 
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Also includes short-term initialization, which develops rolling average 
statistics used by forecaster 102, according to techniques that are known in the 
art. Simulates daily data aggregation and statistical update processing for a 
number of capture dates. 

Data Aggregation 304: Loads daily reservations and status data for each 
property, and aggregates into buckets related to revenue management. This is 
accomplished by loading data extract files into a staging area, and calling data 
aggregation scripts to process the data into tables, according to techniques that 
are known in the art. Data aggregation 304 takes input from data capture, con- 
trol curve, room type category detail, yield GNR transactions, price code, and 
lost business data. The results stored in database tables for use by forecaster 102, 
optimizer 103, and decision support tools 309. 

User Interface 305: Facilitates user interaction with system 300 via screen 
displays, keyboard and mouse input interfaces, and the like. 

Reports 306: Facilitates selecting scheduling, viewing, and printing out- 
put. Reports 306 are viewed, in one embodiment, through user interface 305 or 
through a web interface, as for example via an intranet. 

Forecaster / Demand Predictor 102: Generates demand forecasts for each 

day in the forecast horizon, for each property, according to techniques that are 

known in the art. These forecasts are used by optimizer 102 and decision sup- 
port tools 309. Forecaster 102 determines forecasts using transaction data, busi- 
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ness statistics, daily arrival information, and the like. Data for forecaster 102 is 
generally aggregated by aggregator 304. 

Optimizer 103: Maps projected demand from forecaster 102 to available 
inventory, and recommends optimal bid prices and overbooking levels by inven- 
tory date and room category. Bid prices are adjusted by gaming value to gener- 
ate bid price recommendations for recommendations module 307, as described 
above. Performs mapping for each day in the forecast horizon. 

Recommendations 307: Filters results of optimizer 103 to a level that can 
be controlled by the booking process, and generates bid prices and overbooking 
recommendations for each customer segment in each room category. In one em- 
bodiment, competitive market response module 312 determines a market com- 
posite price based on room prices charged by competing hotel properties, and 
recommendations 307 are automatically adjusted based on the market composite 
price to generate a Cl-adjusted bid price, as described above. 

In one embodiment, recommendations module 307 checks against current 
recommendations in the reservation environment to produce new recommenda- 
tions only when the current recommendations differ from the optimal recom- 
mendations generated by optimizer 103. An action index scales recommenda- 
tions by a sliding numeric scale, based on the revenue consequences of failure to 
accept the recommendations. The action index measures relative impact of a 
recommendation compared with the most revenue impacting inventory date. 
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Thresholds may be defined, specifying when recommendations should not be 
sent, or should automatically be accepted ("auto-piloted"), or should be recom- 
mended for review. Recommendations module 307 further processes overbook- 
ing and bid price recommendations, as well as reservation requests based on 
gaming value and other customer segment factors. 

In one embodiment, recommendations may be automatically transmitted, 
or held for manual review by a user, or both, as desired. Automatic transmission 
can be effected as part of a periodic batch process, for example on a daily basis. 
Alternatively, recommendations may be transmitted in response to users flag- 
ging generated recommendations and/ or building transaction updates via user 
interface 305. Received recommendations can be integrated into reservation 
booking systems so that future bookings automatically take into account the rec- 
ommended bid prices and overbooking levels. 



In one embodiment, recommendation files are divided by property, for 
improved distribution of transaction load. One example of the file format that is 
generated by the present invention contains records with the following fields: 



Field Name 


Description 


Recommendation ID 


Unique identifier for the recommendation 


Hotel ID 


Unique identifier for the hotel or property 


Arrival Date 


Day of arrival for the data in this record 
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Customer Segment 


Unique identifier for the customer segment 


Room Type Cate- 
gory 


Unique identifier for the room type category 


Bid Price 


Recommended bid price for this arrival date, room type 
category, and customer segment 


Breakpoint 


Recommended breakpoint for this arrival date, room type 
category, and customer segment 


Recommended 
Overbooking Level 


Recommended overbooking level for this arrival date, 
room type category, and customer segment 



Recommendation files, once received, are processed by the receiving sys- 
tem. Once processing is complete, a recommendations result file may be trans- 
mitted back to recommendations module 307, containing the original recom- 



mendation record identifier plus an indicator of the status of the recommenda- 
tion (success or error). The result may optionally contain error text, if applicable 
An example of the format for the result file is as follows: 



Field Name 


Description 


Recommendation ID 


Unique identifier for the recommendation 


Recommendation 
Type 


Type of recommendation: bid price, or overbooking 


Response Code 


0 = success; 1 = failure 
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Response Message 


Error message stating reason for failure, if applicable 


Text 





Re-Optimization 308: Provides functionality for re-optimizing overbook- 
ing and bid prices after changing forecasts. The user can override the forecasted 
demand and re-optimize overbooking and bid price recommendations for the 
room category in question. 

Re-optimization 308 is initiated when the user overrides the forecast for 
one or more recommendations and/ or manually triggers a re-optimization. In 
response, re-optimization is performed to generate new overbooking and bid 
prices, which are then provided to the user for review. 

Database and Decision Support 309: Maintains aggregated daily de- 
mand data, forecasts and supporting statistics, and optimization results, for use 
in reporting and other decision support functions, according to techniques that 
are known in the art. 

Database 309 acts as a data store for revenue management data (property 
databases) and system information, and may be implemented using any com- 
mercially available database. Database 309 provides structures and processes for 
transforming transaction data into revenue management data, and provides in- 
put to and stores output of forecaster / demand predictor 102 and optimizer 103 
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modules. Database 309 also provides a consistent data set for reports module 
306, and may be a data source for third-party reporting tools. 

Database 309 is used by aggregation module 304 to store aggregated data. 
Forecaster 102 reads aggregated data from database 309 and stores statistics in 
5 database 309. Optimizer 103 reads statistics from database 309 and stores rec- 
ommendations in database 309. Database 309 also stores defined parameters and 
overrides received from user interface 305, and provides data for reports 306. A 
purge process (which may be included in utilities 311) may be provided to delete 
or archive historical data older than a specified amount of time, from database 
20 309. 

Utilities 311: Performs various system utilities, such as task generation 
and report generation. For example, a task scheduler executes a sequence of 
batch jobs in a Unix server environment, including data aggregation, forecasting, 
optimization, and reporting activities, of various modules of system 300. On- 

15 demand jobs such as user reports may also be managed through the task sched- 
uler. Daily, weekly, or monthly jobs may be specified and executed. 

A report generator provides functionality for query and display of data in 
tabular form. Data for the reports may be extracted from database 309, as speci- 
fied by the user. Query criteria may be customized and saved for future use, as 

20 is known in the art of report generation. Reports may be scheduled to run on a 
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periodic basis, or executed on demand. Predefined report types may be pro- 
vided, and customization functions available for the predefined report types. 

Competitive Market Response Module 312: In one embodiment, as de- 
scribed above, the present invention develops a Cl-adjusted bid price, which 
takes into account competitive market information. Functionality for developing 
the Cl-adjusted bid price may be included in recommendations module 307, or 
may be provided in a separate Competitive Market Response (CMR) module 312. 

The competitive market response functionality of the present invention al- 
lows a user to enter data describing competitive room prices, which may be ob- 
tained from published advertising or by inquiring at competing hotels. Data 
from targeted competitors is weighted to determine a market composite price re- 
flecting overall market conditions for a particular type of room. CMR module 
312 adjusts recommended bid prices according to the determined market com- 
posite price. 

In one embodiment, CMR module 312 operates as follows. User interface 
305 includes a screen for establishing a number of targeted competitors, along 
with assigned weights for each. The market composite price is determined by 
weighted average among the applicable room prices of the targeted competitors. 

User interface 305 includes a second screen for inputting competing 
prices. A user may call competing properties and/ or enter prices from published 
ads or listings. This screen may also be used for viewing and editing previously 
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entered prices. Alternatively, a data extract procedure may be implemented 
which facilitates the input of competing prices by an automated process, such as 
from online sources. 

After optimizer 103 determines optimal bid prices, CMR module 312 
makes adjustments based on the variance between the determined bid price and 
the market composite price. A market influence parameter may be established, 
to specify how strongly the variance affects the recommended bid price. In one 
embodiment, the percentage change resulting from the application of CMR 
module 312 is similarly applied to other room categories, so as to keep other 
room categories priced appropriately within the competitive environment. CMR 
module 312 may be implemented so as to automatically adjust prices, or to 
prompt the user before adjustments are made. If desired, adjustment recom- 
mendations can be displayed even when they are not adopted. 

In one embodiment, CMR module 312 and user interface 305 implement 
additional functionality related to competitive prices. For example, UI screens 
may be provided for price comparison impact data, displaying changes in 
quoted prices and market composite prices. Denial data is also displayed, so that 
the user can infer changes in demand caused by fluctuations in market composite 
prices. For example, a first graph may show room price information, including 
composite price, quoted price, initial bid price, Cl-adjusted bid price, and rec- 
ommended bid price. A second graph may show denial statistics, including 
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rooms sold, denials, and regrets. Both graphs may be displayed along a time axis 
showing days in the planning horizon. Thus, the user is able to identify increases 
in denials, decreases in rooms sold, and data showing whether these changes are 
caused by changes in market composite prices. Adjustments can then be made 
based on the displayed data. Reports containing this information may also be 
generated. 

In one embodiment, a market influence screen may also be provided as 
part of user interface 305 in conjunction with CMR module 312. The market in- 
fluence screen enables a user to specify and maintain parameters for automated 
adjustment of bid prices and/ or room prices in response to significant variance 
between the market composite price and quoted prices. The user specifies mar- 
ket influence factors to determine the level of response to variances. Factors 
range from 0% to 100%, and are multiplied by the measured variance to deter- 
mine the automatic adjustment to bid prices and room prices. Separate factors 
may be specified for different days of the week, time periods, or other subdivi- 
sions. In one embodiment, variance is measured for one room category, such as 
the lowest- value room category; in other embodiments more than one room 
category may be monitored. The present invention adjusts bid prices and room 
prices by the variance from market composite price, multiplied by the appropri- 
ate influence factor, to obtain adjusted bid prices and room prices. 
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In addition, a competitor price report, and other reports, may be gener- 
ated and output by reports module 306, based on data from CMR module 312. 

User Interface 

In one embodiment, the present invention is implemented as functionality 
in a computer system for revenue management, according to techniques that are 
known in the art. User interface 305 facilitates user access to the features and 
benefits of the invention, and in particular provides means for input and access 
to stored and generated data related to hotel revenue management functions. 
The following description of several screens included in user interface 305 is 
merely exemplary; one skilled in the art will recognize that many other designs 
or types of screens may be provided without departing from the invention as 
claimed. 

Recommendations Review Screen 

Referring now to Fig. 4, there is shown a screen shot of a recommenda- 
tions review screen 2000. Screen 2000 provides functionality for reviewing and 
modifying initial bid price and overbooking recommendations. Current values 
2001 are displayed, including the date, property, days left, forecast total sold, 
status, overbooked quantity, manager hold, total demand, out-of-order rooms, 
actual capacity, current group block, current group sold, and current group 
available. 
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Table 2002 shows overbooking levels for each room category, including 
recommended levels, current levels, and adjusted levels. Additional fields as 
displayed in one embodiment include current sold, forecasted sold, forecasted 
no-shows, capacity, and remaining sold forecast. Action index 2003 is also dis- 
played, as described above. Table 2004 shows, for a number of customer seg- 
ments, the unadjusted forecast demand, user adjustment, adjusted forecast de- 
mand, initial bid price, recommended bid price, and adjusted bid price. 

When the user chooses to adjust the forecasted demand or bid price, he or 
she right-clicks on the targeted recommendation. A pop-up screen, shown in 
Fig. 5, facilitates entry of modified forecast or bid price. Event button 2005 al- 
lows access to event information. Optimize button 2006 initiates re-optimization 
based on the newly modified information. OK button 2007 enters all changes 
and dismisses screen 2000. Cancel button 2008 dismisses screen 2000 without en- 
tering changes. 

Adjust Bid Price Screen 

Referring now to Fig. 5, there is shown a screen shot of an adjust bid price 
screen 2100. Screen 2100 provides functionality for adjusting forecasted demand 
or bid prices. The user is able to review previously adjusted bid prices or ad- 
justed forecast demand, and disable previous adjustments if desired. 
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In one embodiment, screen 2100 is presented when the user right-clicks on 
a targeted recommendation in screen 2000, or when the user selects an appropri- 
ate command from the main screen. In one embodiment, screen 2100 also in- 
cludes a description of the day of week, room category, and customer segment 
that apply to the bid price being modified. Screen 2100 contains fields for unad- 
justed forecast demand 2101, user-adjusted demand 2102 (modifiable), adjusted 
forecast demand 2103, initial bid price 2105, recommended bid price 2106, CI- 
adjusted bid price 2107, user-adjusted bid price 2108 (modifiable), and "comp" 
and casino price override 2109. Checkboxes for removing previous adjustments 
2104 and removing price overrides 2110 are also provided. OK button 2111 ac- 
cepts the user's changes and dismisses screen 2100. Cancel button 2112 dismisses 
screen 2100 without accepting changes. 

One skilled in the art will recognize that many other screens may be pro- 
vided in connection with the present invention. 

Reports 

The system generates various types of reports, as are known in the prior 
art and as improved by the present invention, based on stored and generated 
data, including forecasts, optimizations, recommendations, booking data, and 
the like. Reports may be generated in response to user requests, or they may be 
automatically generated at specified times. 
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In general, reports generated by the present invention can be viewed on a 
user's workstation or monitor, or printed, or exported onto magnetic media, or 
transmitted across a network, according to techniques that are known in the art. 
In particular, users can view reports through user interface 305 or using a 
browser via a network such as an intranet. 

The invention advantageously provides gaming reports which provide 
users with useful information related to gaming value. 

• Casino Block Analysis Report: A comparison of group and casino 
bookings with respective blocks defined. Shows transient actual 
sold, forecast transient demand, and recommended optimal sold. 

• Competitor Price Report: A listing of competitors 7 prices, along 
with respective weights. 

• Historic Revenue/ Yield Report: A summary of yield and reve- 
nue performance for both room prices and gaming value. 

Network Configuration 

Referring now to Fig. 6, there is shown a block diagram of a network 2600 
configuration useful for implementing an embodiment of the present invention. 
In one embodiment, the present invention is implemented on a client/ server ar- 
chitecture including a database and application server 2601, which acts as a cen- 
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tral repository and which generates the forecast and optimization data and proc- 
esses. Users access the data in the system via workstations 2602 connected over a 
network. Individual users may have different access rights and privileges, which 
are set and controlled via user accounts and security groups, as is known in the 
art. Users may be hotel employees, or even individual customers themselves, 
accessing the server 2601 via the Internet to obtain room reservations. 

Lodging Management System (LMS) 2604 connects to server 2601 and 
supplies data used by the various functional modules of the present invention. 
Inventory control recommendations generated by the invention are transmitted 
to LMS 2604 and applied to LMS inventory counts. 

LMS 2604 also receives data from a telephone center and properties 2603, 
and communicates with Casino Management System (CMS) 2605. The operation 
of these components is described in related U.S. Patent Number 5,761,647, for 
"National Customer Recognition System and Method." 

User interface functionality, including viewing reports, accepting and re- 
jecting recommendations, and system maintenance, is accomplished via various 
ones of the client workstations 2602. Communications with server 2601 is facili- 
tated by conventional network protocols and hardware. In one embodiment, cli- 
ent access via workstations 2602 operates via a browser interface over a network 
such as an intranet. 

Customer Valuation 
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As discussed above, one example of indirect value that may be deter- 
mined and employed in the context of the present invention is customer gaming 
value, also called customer value. In the context of a casino/hotel operation, 
customers who generate higher gaming revenue might be offered more favorable 
room rates. Alternately, customers who generate higher gaming revenue might 
be offered more or higher valued complimentary (comp) items. 

In one embodiment, the customer value may be provided as an expected 
value or an actual value. The value is determined based on actual or predicted 
gaming behavior by, for example, taking the average theoretical win (TW) and 
applying property-specific profitability margins depending on, for example, 
game type and player value ranges. In one embodiment, the average theoretical 
win is determined on a property-specific basis. In other words, the same cus- 
tomer gaming behavior will not necessarily result in the same theoretical win if 
valued for two different casinos (properties). Similarly, at a given property, 
theoretical wins are computed separately for each gaming type. Thus, a cus- 
tomer's losing $200 to slot machines may be valued differently than the cus- 
tomer's losing $200 to a table game such as Blackjack because of the costs and 
overhead associated with the different gaming types. Figs. 7-16 show an exam- 
ple of a customer valuation method and system for determining one type of indi- 
rect value, specifically a customer gaming value, which is also called a customer 
value. 
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Fig. 7(a) is a flow chart showing a relationship between an embodiment of 
the present customer evaluation method and a resource management system, 
such as that shown in Figs. 1-6. In the described embodiment, a customer value 
is determined for a customer across a brand using a property-specific analysis. 

5 When valuing a potential hotel/ casino customer, for example, this means that a 
customer value is determined for the customer at the individual casino or hotel 
in which the customer is interested, but the customer value is determined using 
information from the customer's activities at one or more other casinos and ho- 
tels in the system, if such information is available. Thus, for example if the cus- 

10 tomer is interested in a hotel in Las Vegas, but has previously stayed or gambled 
at other affiliated hotels in another city, then information from the other hotels 
also may be used to determine a customer valuation specific to the hotel in Las 
Vegas. 

In the example of Fig. 7(a), the customer valuation system 3501 is capable 
15 of determining a control segment for the customer (one of 10 possible control 
segments in the example). The reservation management system 3502 uses the 
control segment as described above in connection with Figs. 1-6 to determine a 
price range at which to offer the customer a room. In the example, the customer 
valuation system also is capable of determining a customer segment within the 
20 control segment for the customer (one of 64 possible customer segments in this 
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example). The reservation management system uses the customer segment to 
rate the customer within his assigned control segment at the time of booking. 

Fig. 7(b) is a flow chart of three contexts in which a customer valuation 
method might be used in a hotel/ casino system: Reservations, Booking, and Set- 
tlement (checkout). During the reservations operation 3512, the system receives 
a request to book or reserve a resource, such as a hotel room at a specific prop- 
erty for one or more customers. The system determines a control segment for 
the customer for the specific property requested. The same customer may be as- 
signed different control segments for different properties, depending on his past 
activities. As described in further detail below, the control segment for the cus- 
tomer at this property is determined in accordance previously saved data across 
multiple affiliated hotels. Thus, for example, if a customer requests a room in 
Las Vegas, but has stayed at affiliated hotels in the same chain in another city, 
the customer's actions in those cities will be used to determine his value in Las 
Vegas. These same previous actions may result in different control segments for 
different hotels. For example, if the customer usually plays the slot machines 
and there are no slots at a particular hotel, his value may be lower at that hotel, 
than in hotels that have slots machines. In the example, there are 10 possible 
control segments, representing different values of customers. Customers with a 
higher potential value will receive more favorable room rates from the reserva- 
tion system, 
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If the customer chooses to reserve a room at the offered price 3514, then 
the room is booked 3516, and the customer valuation system determines a cus- 
tomer segment within the customer's control segment. This customer segment is 
used to further categorize customers within a control segment. 

Once the customer has settled (checked out) 3518, the customer valuation 
process preferably is invoked again to determine an actual value for the cus- 
tomer, based on his actions during his stay. 

The following paragraphs describe an embodiment of a method to deter- 
mine a customer profitability value. It will be understood that other implemen- 
tations of the present invention can be made. Figs. 8-12 show table data struc- 
tures used in the described embodiment. Other embodiments may use different 
data structures or similar data structures with different and/ or additional fields. 
In the described embodiment, each table data structure in Figs. 8-12 includes a 
Property ID key (Prop ID), which identifies the customer for which the profit- 
ability determination is being made. 

Fig. 8 shows a data structure 3532 used by the customer valuation method 
and containing property-specific flags and values. The Hotel_Only flag value 
reflects whether only data for hotel stays should be used to compute a customer's 
theoretical win. If only hotel data is used, most customers will end up with a 
higher theoretical win, since it is common for a customer staying at a hotel to 
spend more time gambling and thus to spend more money. The 
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Min_Hotel_Trips_Required field indicates how many hotel trips the customer 
must have made before only hotel data will be considered. Even if the Ho- 
teljDnly flag is true, hotel only data will not be used if the customer has not 
made the minimum number of trips. 

The Property' s„Default_Theoretical„Win (TW) field contains a default TW 
value that will be used for unknown/ unrated customers at this property. If a 
customer has not stayed in this or other hotels in the chain, then the default TW 
will be used. As described below, this value may be modified further in certain 
embodiments if the customer played slot machines during his stay and/ or if 
multiple guests are staying in the room. 

The Unknown_Guest-Multiplier field contains a multiplier to use if more 
than one guest will be staying in the room. For example, if the property's default 
TW for unknown guests is $20, and the unknown guest multiplier for that prop- 
erty is 1.5, then two guests in a room for that property would be given a default 
TW of $30. 

The Default ADR field is the Average Daily Rate that the customer would 
pay at this property. This value is saved and used in later analysis, particularly if 
a customer chooses to turn down the quoted room price, since information on the 
average value of rooms turned down is also interesting in determining future 
room prices. 
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Fig. 9 shows a data structure 3534 used by the customer valuation method 
and containing values associated with a source code for the customer. The 
Source Code field contains a code indicating possible sources of an unknown 
customer, such as special promotions, etc. The source code could also indicate 
the unknown customer's home address. For example, if Calif ornians are known 
to spend more money in Las Vegas than Minnesotans, unknown customers with 
a source code indicating that they are from California may receive a higher 
valuation than those with a source code indicating Minnesota when the re- 
quested room is in Las Vegas. This situation may be reversed in a hotel in Min- 
nesota if data shows that Minnesotans spend more in their home state. 

There may be more than one Source Code per property. Each Source 
Codes has a corresponding Source Code's Default TW field, which contains a De- 
fault TW to use if the unknown customer came from that source. The Default 
TW field preferably contains a different value than the Property's Default TW of 
Fig. 8. For example, a customer is given the Property's Default TW of $30 unless 
the customer is from source BD, in which case the customer would receive a De- 
fault TW of the Source Code's TW of $40. 

Fig. 10 shows a data structure 3536 used by the customer valuation 
method and containing values associated with a daily profit determination for 
the customer. Here, the Minimum and Maximum Daily TW fields form a range 
of TWs. Each daily profit determination table contains multiples ranges, and 
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each range contains multiple Game Type fields, such as Table, Slots, and Other. 
Within each range, each gaming type has a corresponding weighting factor, rep- 
resenting the profit percentage for the game type and TW range. 

Fig. 11 shows a data structure 3538 used by the customer valuation 
method and containing values associated with a nightly profit determination. If 
a customer stays overnight at a hotel, experience shows that the customer will 
actually spend more than one day in the casino. Thus, if a customer's stay in- 
cludes a night time stay, his TW is increased by a predetermined factor. Experi- 
ence has also shown that the more nights a customer stays, the less additional 
dollars per day he will spend. Thus, the customer valuation method determines 
an additional factor based on the number of nights a customer has stayed at a ho- 
tel. Here, the Minimum and Maximum Daily Adjusted Daily Revenue fields 
form a range of minimum adjusted daily revenues. Each nightly profit determi- 
nation table contains multiples ranges, and each range contains multiple Number 
of Nights Reserved values, such as 1, 2, 3, etc. Within each range, each the num- 
ber of nights reserved value has a corresponding weighting factor, representing 
the percentage that TW should be increased for that number of nights and range 
for this property. Thus, if a customer has a minimum adjusted daily revenue of 
$30 and has stayed one night, his revenue will be higher by the factor. In the de- 
scribed embodiment, customers who stay 4 nights or more receive a factor of "1," 
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since it is believed that longer staying customers stop spending more money as 
their length of stay increases. 

Other embodiments, based on a revenue model for certain properties or 
industries will use the factor to lower the adjusted daily revenue, instead of to 
raise it. Other embodiments may use the factor to either raise or lower the reve- 
nue. 

Fig. 12 shows a data structure 3539 used by the customer valuation 
method and containing values associated with control segments and customer 
segments. The control segment field is the field whose value is returned to the 
reservation operation. The customer segment is returned to the booking opera- 
tion. Here, the Minimum and Maximum Nightly Profit fields form a range of 
nightly profits. Each nightly profit determination table contains a range for each 
property and a range of actual maximum and minimum room rates for each 
segment, for both known and unknown customers. The table further contains a 
Rate Descriptor field indicating the range of room rates should be given to vari- 
ous types of customer. For example, a "cornp" value indicates that this is the 
room rate range for a comped customer. A "CI" value indicates that this is the 
room rate range at a high priced casino hotel. 

Fig. 13(a) is a flow chart showing an overview 3540 of the customer valua- 
tion method used with a reservation operation. Once a request for a resource at a 
specific property for a specific customer is received 3542, the system determines 

-57- 

Case 6497 

19538/06497/DOCS/1224713.3 



a theoretical win (TW) 3544 for that customer based on the customer's past ac- 
tions at this and other properties in the chain. This TW value is based on past 
activities of the customer and can vary for different requested properties. If the 
guest has an incentive to book the room (such as a coupon), his incented flag is 

5 set 3546. Expected total daily profits are determined for this customer at this ho- 
tel, based on his past actions across the chain 3547, If the customer has stayed 
overnight in the past, his expected total daily profits are adjusted by a factor de- 
pending on the number of nights he has stayed in the past 3548, since overnight 
stays are assumed to be more profitable in this embodiment. Finally, based on 

10 the determined information, the system determines a control segment for this 
guest at this property. 

It will be understood that the above method is an example only and 
should not be taken in a limiting sense. For example, other embodiments of the 
invention might add or omit steps or might change the order of steps. As a fur- 

15 ther example, the incented flag may not be used in other embodiments. Simi- 
larly, the nightly profit determination might not be used in other embodiments. 

Fig. 13(b) is a flow chart showing an overview of the customer valuation 
method 3552 used with a booking operation. In the described embodiment, the 
customer valuation system uses information, such as the control segment and the 

20 accepted room rate, determined during the reservation process, to determine a 
customer segment within the previously determined control segment 3554. 
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Figs. 14(a)-14(c) are flow charts showing details of the customer valuation 
method used with a reservation system. In the described embodiment, the in- 
puts 3562 to the customer valuation process during reservations are: an ID for 
the requested property (e.g.. Las Vegas); a customer source code; a customer of- 
fer code; a number of nights requested to be reserved; a number of extra adult 
customers; and a flag indicating whether this customer is a previously known 
customer who has stayed at least one hotel or casino in the chain associated with 
this brand of hotels/ casinos. 

Fig. 14(a) shows a method to determine a TW for the specific customer 
and property specified. If there are no previously saved data for this customer 
3564, then the customer is an unknown customer and the system will use one of 
the default TW value specific to the requested property, as shown in the tables of 
Figs. 8 and 9. If there is a source code for the customer 3566, the default TW for 
that source code is used 3568 (see Fig. 9). If there is no source code for the cus- 
tomer 3566, the default TW for the property is used 3570 (see Fig. 8). In either 
case, control passes to step 3582 of Fig. 14(b). 

Table 2 shows an example of the data structure of Fig. 8 populated with 
example data. The columns of Table 2 correspond to those of Fig. 8. The data 
shown in Table 2 is all for the same property ID (ID=104), It will be understood 
that a complete data strcuture would have data for each property in the chain of 
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properties, so that the methods of Figs. 14-15 could be performed for any prop- 
erty in the chain. 

If the customer is known 3564, then the system determine whether the 
customer has stayed at enough hotels that a "hotel only" adjustment needs to be 
made. If the hotel only flag (not shown) for this customer is true and the cus- 
tomer has stayed at a hotel for at least a specified minimum number of trips 3572, 
then just information from hotel stays is used to determine the customer's TW 
3576. As discussed above, experience has shown that using hotel only data will 
result in a higher TW since hotel stays usually result in higher gambling pro- 
ceeds that day trips to casinos. For example, if a customer lives in Joliet and 
regularly gambles during day trips to Joliet casinos, but twice a year goes to Las 
Vegas, stays in hotels, and gambles, it is assumed that using only data from his 
hotel stays will result in a higher and more accurate TW for other hotel stays 
than would result if the day trips to Joliet were also considered. After the TW is 
determined in this case, control passes to step 3582 of Fig. 14(b). 

Similarly, if there are data for this customer, but all data is hotel data 3574, 
the customer's TW is determined based on just hotel gaming data 3576. 

Certain embodiments may set the hotel only flag to true for all customers, 
resulting in the analysis described above. Other embodiments may always set 
the hotel only flag to false, or may not include a hotel only flag, resulting in skip- 
ping the above analysis. 
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If the hotel only flag is false and (or true, but not enough trips have been 
taken) and there is data from previous trips 3579, the data from all the customer's 
past trips to various hotels in the chain are used to determine the customer's TW 
for the specific property requested. 

The actual TW calculation is known to persons of ordinary skill in the art, 
although in the described embodiment, the TW is calculated using the cus- 
tomer's activities from multiple affiliated hotels/ casinos, not just from the prop- 
erty requested. 

Fig. 14(b) shows a method for determining a value of an incented flag for 
the customer within the customer valuation system. If the offer code for the cus- 
tomer (not shown) is blank 3582, then the incented flag for the customer is set to 
false 3586. Otherwise, the incented flag is set to true 3584. In either case, control 
passes to step 3588. 

Fig. 14(b) also shows a method for determining an expected total daily 
profit for the customer (or an actual daily profit if the valuation process is in- 
voked during the settlement operation). If no default TW was used 3588, then 
there is previous data for this customer. In the described embodiment, the ex- 
pected average daily profit is determined as follows: 

- For each hotel or casino for which we have data for this customer: 

- For each gaming type at that hotel/ casino: 
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- Use the greater of 100% of the daily average TW for all guests at this 
location and gaming type OR 40 A % of the actual average TW for this 
customer to determine daily profit. 

- Look up the daily profit factor for each gaming type and property ID 
(see Fig. 10). 

- Multiply each daily profit by the daily profit factor by gaming type to 
get the adjusted daily profit factor per gaming type. 

- Sum the adjusted daily profit by gaming type to get the total daily 
profit for this customer at this hotel/ casino 

Table 3 shows an example of the data structure of Fig. 10 populated with 
example data. The columns of Table 3 correspond to those of Fig. 10. The data 
shown in Table 3 is all for the same property ID (ID=104). It will be understood 
that a complete data structure would have data for each property in the chain of 
properties, so that the methods of Figs. 14-15 could be performed for any prop- 
erty in the chain. 

If a default TW was used 3588, and the number of extra adult customers is 
greater than zero 3592, the TW is adjusted by an unknown customer multiplier 
3594 (See Fig. 8). Experience has shown that multiple customers spend more 
money than single customers. Therefore, if there is more than one customer, the 
TW is increased. In certain embodiments, a multiple is only used if there are 
more than a predetermined number of additional customers. In certain em- 
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bodiments, different multiples exist for different numbers of additional custom- 
ers. 

If a default TW was used 3588, the default TW is adjusted if the customer 
has previously spent time playing slot machines 3596/3598. Because slot ma- 
chines are generally less profitable than other types of machines, if the cus- 
tomer's previous play has involved mostly slots, then the default TW is adjusted 
downward. In alternate embodiments, the default TW is adjusted upwards if the 
customer played mostly non-slot machine types of games. After step 3598, the 
system has determined the total daily profits for the customer. When the deter- 
mination is performed during the reservations operation, the expected daily 
profits have been determined. During the settlement operation, a similar method 
is used to determine the actual daily profits for the customer's current stay. 

In Fig. 14(c), the daily profits are adjusted if the customer has stayed over- 
night in the past. Because overnight trips are more profitable than day trips, the 
daily profits value is adjusted upwards as described if the customer has stayed 
overnight in the past. 

If the customer is known and data from all his trips is being used 3602, the 
average daily profit is adjusted in accordance with a nightly profit factor and 
number of nights reserved. The system looks up the nightly profit factor (see 
Fig. 11) and multiplies the daily profit by the nightly profit factor to determine 
the nightly profit. This nightly profit is either an expected nightly profit or an 
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actual nightly profit, depending on the point in the reservation process that the 
customer valuation system is being invoked. If the customer is not known, no 
adjustment is performed, and the daily profits are used as the nightly profits 
3608. 

Table 4 shows an example of the data structure of Fig. 11 populated with 
example data. The columns of Table 4 correspond to those of Fig. 11. The data 
shown in Table 1 is all for the same property ID (ID=104). It will be understood 
that a complete data structure would have data for each property in the chain of 
properties, so that the methods of Figs. 14-15 could be performed for any prop- 
erty in the chain. 

Once the nightly profits (expected or actual) are determined, the customer 
valuation system looks up a control segment in the data structure of Fig. 12. Us- 
ing the known customer flag, the expected nightly profit, and the incented flag, 
in that order of importance, the system looks up the control segment for the cur- 
rent customer 3612. If no match is found 3614, an error has occurred. The de- 
scribed embodiment handles the error by using the closest row in the data struc- 
ture where the known customer flag is the same for the control segment. In the 
described embodiment, the expected nightly profit, control segment, and the in- 
cented flag are returned to the reservation operation 3618. 

Table 1 shows an example of the data structure of Fig. 12 populated with 
example data. The columns of Table 1 correspond to those of Fig. 12. The data 
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shown in Table 1 is all for the same property ID (ID=104). It will be understood 
that a complete data structure would have data for each property in the chain of 
properties, so that the methods of Figs. 14-15 could be performed for any prop- 
erty in the chain. It should be noted that the same information about a cus- 
tomer's previous actions can cause the customer to be categorized into different 
control segments and/ or different customer segments for different properties. 
Thus, the same known flag, nightly profit range, incented flag value, actual room 
cost range, could result in different control segments and/ or customer segments 
for different hotels. The customer segment is determined on a property-specific 
basis, based on data for the current customer across the chain of properties. 

A preferred embodiment uses 10 control segments (e.g., 0-9). Other em- 
bodiments could use some other number of control segments. 

Fig. 15 is a flow chart showing details of the customer valuation method 
used with a booking system to determine a customer segment within a control 
segment. In the described embodiment, the customer valuation method receives 
the previously determined control segment, the known customer flag, the nightly 
profit, the incented flag, the rate description for the room rate accepted by the 
customer, and the average daily expected room cost 3622. The system uses these 
input values to look up the customer segment in the data structure of Fig. 10. 
The rate descriptor can have values representing casino/ hotel rates (e.g., CP1, 
CP2) 3524 or can have values representing comped rates 2638. If an error occurs 
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and no match is found in the data structure, the system uses the closest row 
within the specified control segment where the known customer flag in the data 
structure matches the input known customer flag and the nightly profits are 
within the minimum/ maximum range. The order or importance for matching 
the remaining fields preferably is incented flag, rate description, and room range 
cost. 

A preferred embodiment uses 64 customer segments (e.g., 1-64). Other 
embodiments could use some other number of customer segments, or could dis- 
tribute them unevenly between the control segments. 

Fig. 16 shows an example screen used during the reservations operation. 
In the example shown, the customer has been placed into control segment 8, 
which yields a room rate (e.g., $89/ night). The rate is then offered to the cus- 
tomer, who then books a room (resulting in a customer segment). In the de- 
scribed embodiment, a " prevailing rate" is also displayed (e.g., $99/ night). This 
rate is displayed so that an operator can tell the customer how much money he is 
saving. 

When a customer settles (checks out of his room), his actual daily profit 
for the trip is determined and stored using a method similar to that described 
above for determination of an expected daily profit in the reservations operation. 



Table 1: Control Segments and Customer Segments 



PROPID 


CTLSEG 


CSTSEG 


KNOWN 


MINPROF 


MAXPROF 


INCENT 


MINCOST 


MAXCOST 


RATEDESC 
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Table 2: Property-specific Flags and Values 



PROPCD 


USEHTL 


MINTRIP 


DEFTHEO 


GSTMULT 


DEFADR 


104 


N 


2 


20 


1.0 


250 



Table 3: Daily Profit Determination 



PROPCD 


MINTHEO 


MAXTHEO 


GMTYPE 


MULT 


104 


0 


149 


SLT 


.60 


104 


150 


999999999 


SLT 


.56 


104 


0 


112 


GAM 


.39 


104 


113 


149 


GAM 


.49 


104 


150 


999999999 


GAM 


.56 


104 


0 


106 


OTHER 


.59 


104 


107 


999999999 


OTHER 


.56 



Table 4: Nightly profit Determination 



PROPCD 


MINTHEO 


MAXTHEO 


NIGHTS 


MULT 


104 


0 


999999999 


1 


1.50 


104 


0 


999999999 


2 


1.25 


104 


0 


999999999 


3 


1.10 


104 


0 


999999999 


4 


1.00 



-69- 



Case 6497 

19538/06497/DOCS/1224713.3 



From the above description, it will be apparent that the invention dis- 
closed herein provides a novel and advantageous system and method of optimiz- 
ing prices for a resource, by taking into account multiple value sources, including 
indirect value. The foregoing discussion discloses and describes merely exem- 
plary methods and embodiments of the present invention. In particular, the 
above-described embodiments present the invention in the context of a ca- 
sino/hotel operation in which room rates are optimized based on actual or ex- 
pected gaming value of customers, As will be understood by those familiar with 
the art, the invention may be embodied in other specific forms without departing 
from the spirit or essential characteristics thereof. For example, other operational 
architectures, data formats, architectures, applications, user interfaces, and proc- 
ess flow schemes may be used. Accordingly, the disclosure of the present inven- 
tion is intended to be illustrative, but not limiting, of the scope of the invention, 
which is set forth in the following claims. 
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